Repository navigation
Conversation
@oven/bun-darwin-x64-baseline is byte-identical to @oven/bun-darwin-x64 (the AVX2 build), so pre-AVX2 Intel Macs get no working binary and no fallback. buildPlatforms had no darwin baseline lane, though platform.ts already declares the npm package and prebuiltSuffix() already requests the baseline WebKit tarball. Gated on oven-sh/WebKit#290, which publishes bun-webkit-macos-amd64-baseline.
|
Two things this lane will need to go green once the WebKit artifact lands:
Possibly also worth adding |
Every other baseline artifact is covered in testPlatforms (linux x64 debian + ubuntu, linux x64 musl alpine, windows x64). darwin x64 baseline had no entry, so the shipped artifact was never exercised — which is how it shipped as the Haswell build unnoticed. Suggested by robobun in oven-sh#34207.
|
All three are right — thanks.
Re #32512: the Nehalem macOS WebKit does build, via WebKit's own unmodified |
|
Cross-reporting a real-hardware test of the artifact this lane produces — Mac Pro 5,1, Xeon X5690 (Westmere, no AVX/AVX2/BMI), macOS 14.7.8. Full report + SHA-256 hashes: anomalyco/opencode#8345 (comment). tl;dr: the WebKit Tested
Heads-up for this lane: once green, a Happy to re-test any updated artifact — this is a permanent no-AVX box. (Minor: the binary self-reports |
|
Your heads-up was right, and it turned out to be the load-bearing point on this whole chain — thank you. You called it precisely: the JIT emits AVX at runtime regardless of the build It was worse than either of us thought. The same assumption lives in a second place — JSC's probe trampoline uses
New build with both halves: https://github.com/tobocop2/opencode-bun-pre-avx2-mac/releases/latest
On your testing point — agreed, and it's worth separating two things. bun's Everything above is verified under Rosetta 2 (Apple M1, macOS 14.6.1), which reports no AVX and reproduced your X5690 results exactly on the previous build — but it's emulation, not Westmere silicon. If you have time to put this one on the X5690, that's the piece I can't get: a no-AVX-at-all CPU clearing a JIT-on workload and a WASM loop. |
WalkthroughChangesDarwin x64 baseline alignment
Possibly related issues
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.buildkite/ci.mjs:
- Line 140: Gate or disable the darwin x64 baseline configuration in the CI
matrix until the pinned WebKit release provides the required baseline tarballs.
Update the entry identified by os "darwin", arch "x64", and baseline true, while
preserving the non-baseline darwin x64 lane.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 9b41694a-4eb5-47d3-b2f6-b0b4eaf1e529
📒 Files selected for processing (2)
.buildkite/ci.mjsscripts/build/deps/webkit.ts
| // these are the darwin artifacts the release ships. | ||
| { os: "darwin", arch: "aarch64", crossCompile: true, distro: "amazonlinux", release: "2023", features: ["docker"] }, | ||
| { os: "darwin", arch: "x64", crossCompile: true, distro: "amazonlinux", release: "2023", features: ["docker"] }, | ||
| { os: "darwin", arch: "x64", baseline: true, crossCompile: true, distro: "amazonlinux", release: "2023", features: ["docker"] }, |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Map the relevant file and surrounding symbols
ast-grep outline .buildkite/ci.mjs --view expanded || true
# Show the relevant section with line numbers
sed -n '120,220p' .buildkite/ci.mjs | cat -n
# Find WebKit pin / artifact naming logic
rg -n "baseline|baseline-LTO|bun-darwin-x64-baseline|webkit|artifact|triplet|crossCompile" .buildkite/ci.mjsRepository: oven-sh/bun
Length of output: 14910
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the file that defines the platform matrix and any related WebKit pin configuration.
git ls-files | rg '(^|/)\.buildkite/ci\.mjs$|webkit|WebKit|baseline|triplet|artifacts|bun-darwin'Repository: oven-sh/bun
Length of output: 1440
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== .buildkite/ci.mjs excerpt =="
sed -n '130,210p' .buildkite/ci.mjs | cat -n
echo
echo "== references =="
rg -n "baseline|baseline-LTO|bun-darwin-x64-baseline|triplet|webkit|artifact" .buildkite/ci.mjsRepository: oven-sh/bun
Length of output: 11124
🌐 Web query:
Bun WebKit baseline artifact bun-darwin-x64-baseline baseline-LTO WebKit autobuild
💡 Result:
The bun-darwin-x64-baseline artifact in Bun is intended to provide a version of the Bun runtime compatible with older Intel processors (pre-Haswell, such as Ivy Bridge) that lack support for advanced instruction sets like AVX2 and BMI2 [1][2]. However, historically, this artifact has faced technical issues regarding its WebKit dependency. Because Bun relies on a prebuilt WebKit library, a true "baseline" macOS x64 binary requires that the linked WebKit library also be compiled for a baseline CPU target (e.g., -march=nehalem) [3][4]. In the past, the bun-darwin-x64-baseline artifact was often incorrectly linked against the standard "modern" macOS WebKit (which includes BMI2 instructions like shlx), causing the Bun binary to crash with an SIGILL (Illegal Instruction) error upon launch on older CPUs [3][1]. Key points regarding these artifacts include: * Architecture Compatibility: The standard Bun binary requires AVX2 support [2]. The -baseline suffix signifies a build intended for CPUs that lack these instructions [2]. * WebKit Linking: Bun's build system uses specific suffixes (such as -baseline, -lto, or -musl) to select the appropriate prebuilt WebKit artifact [4][5]. For Linux and Windows x64, dedicated baseline WebKit artifacts exist [4]. For macOS, the lack of a corresponding baseline WebKit artifact has previously led to the bun-darwin-x64-baseline binary essentially acting as a non-baseline build, which can trigger crashes on unsupported hardware [3][6]. * Build System Enforcement: To prevent the distribution of misleading artifacts, the Bun build system has been updated to reject the creation of macOS "baseline" binaries unless a genuinely compatible baseline WebKit artifact is available [3]. * LTO (Link Time Optimization): The baseline-LTO terminology refers to a configuration that combines the baseline CPU target requirements with Link Time Optimization for performance. WebKit artifacts are often built with either LTO or debug symbols, and the build system ensures the suffix matches the artifact to avoid linking mismatches [4][5]. As of recent updates, the development team has been working on introducing specific baseline macOS WebKit lanes to properly resolve these crashes and provide a functional baseline experience for older macOS hardware [6].
Citations:
- 1: bun-darwin-x64-baseline crashes with SIGILL on Ivy Bridge CPUs due to BMI2 instructions #32511
- 2: https://bun.com/docs/bundler/executables.md
- 3: build: reject prebuilt baseline macOS builds (no Nehalem macOS WebKit) #32512
- 4: https://github.com/oven-sh/bun/blob/1cc83768/cmake/tools/SetupWebKit.cmake
- 5: https://github.com/oven-sh/bun/blob/74e191b3/scripts/build/deps/webkit.ts
- 6: macOS: no x64 baseline build —
@oven/bun-darwin-x64-baselineis byte-identical to the AVX2 default #34206
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== scripts/build/deps/webkit.ts outline =="
ast-grep outline scripts/build/deps/webkit.ts --view expanded || true
echo
echo "== relevant webkit.ts lines =="
rg -n "baseline|LTO|artifact|darwin|macOS|webkit" scripts/build/deps/webkit.ts
echo
echo "== SetupWebKit.cmake lines =="
fd -a 'SetupWebKit.cmake' . || trueRepository: oven-sh/bun
Length of output: 3058
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== package README excerpts =="
sed -n '1,220p' packages/bun-release/npm/@oven/bun-darwin-x64-baseline/README.md | cat -n
echo
sed -n '1,220p' packages/bun-release/npm/@oven/bun-darwin-x64/README.md | cat -n
echo
echo "== baseline package references =="
rg -n "bun-darwin-x64-baseline|baseline-LTO|WebKit" packages/bun-release/npm/@oven/bun-darwin-x64-baseline packages/bun-release/npm/@oven/bun-darwin-x64Repository: oven-sh/bun
Length of output: 612
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== scripts/build/deps/webkit.ts relevant section =="
sed -n '1,260p' scripts/build/deps/webkit.ts | cat -n
echo
echo "== any baseline-specific references in webkit setup =="
rg -n "baseline|LTO|artifact|download|prebuilt|darwin|x64" scripts/build/deps/webkit.tsRepository: oven-sh/bun
Length of output: 16062
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== SetupWebKit.cmake and related files =="
fd -a 'SetupWebKit.cmake' .
fd -a 'WebKit.cmake' .
fd -a 'webkit' cmake scripts | sed -n '1,200p'
echo
echo "== package and docs references to darwin x64 baseline =="
rg -n "bun-darwin-x64-baseline|baseline-LTO|WebKit" packages docs scripts cmake .claude -g '!**/node_modules/**'Repository: oven-sh/bun
Length of output: 34822
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== scripts/build/config.ts relevant baseline/lto section =="
sed -n '730,790p' scripts/build/config.ts | cat -n
echo
echo "== scripts/build/profiles.ts relevant release/profile section =="
sed -n '130,170p' scripts/build/profiles.ts | cat -n
echo
echo "== scripts/build/deps/webkit.ts prebuilt and build usage =="
sed -n '188,430p' scripts/build/deps/webkit.ts | cat -nRepository: oven-sh/bun
Length of output: 18811
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== test/build lane construction around baseline =="
sed -n '740,840p' .buildkite/ci.mjs | cat -n
echo
echo "== release step / artifact selection hints =="
sed -n '1040,1075p' .buildkite/ci.mjs | cat -n
echo
echo "== build step generation around triplets and prebuilt webkit =="
sed -n '540,700p' .buildkite/ci.mjs | cat -nRepository: oven-sh/bun
Length of output: 14080
🏁 Script executed:
#!/bin/bash
set -euo pipefail
tag="autobuild-4895f45dfbd0d1226c4d41799887bc0ecb9f341b"
echo "== release =="
gh api "repos/oven-sh/WebKit/releases/tags/${tag}" --jq '.tag_name, .name, .assets[].name' || true
echo
echo "== matching asset names =="
gh api "repos/oven-sh/WebKit/releases/tags/${tag}" --jq '.assets[].name' | rg 'bun-webkit-macos-amd64(-baseline)?(-lto)?\.tar\.gz|bun-webkit-macos-arm64'Repository: oven-sh/bun
Length of output: 2123
🏁 Script executed:
#!/bin/bash
set -euo pipefail
tag="autobuild-4895f45dfbd0d1226c4d41799887bc0ecb9f341b"
gh api "repos/oven-sh/WebKit/releases/tags/${tag}" --jq '.assets[].name' | sortRepository: oven-sh/bun
Length of output: 1739
Gate the darwin x64 baseline lanes until the matching WebKit tarball lands. The pinned autobuild-4895f45dfbd0d1226c4d41799887bc0ecb9f341b release only has bun-webkit-macos-amd64.tar.gz and bun-webkit-macos-amd64-lto.tar.gz; it does not publish bun-webkit-macos-amd64-baseline.tar.gz or bun-webkit-macos-amd64-baseline-lto.tar.gz, so the build will fail when fetching WebKit.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.buildkite/ci.mjs at line 140, Gate or disable the darwin x64 baseline
configuration in the CI matrix until the pinned WebKit release provides the
required baseline tarballs. Update the entry identified by os "darwin", arch
"x64", and baseline true, while preserving the non-baseline darwin x64 lane.
|
Closing this. bun main solved the problem a different way. Baseline is the default now. The suffix is gone. oven-sh/WebKit#290 is closed for the same reason. One fix is still open: oven-sh/WebKit#292. JSC assumes AVX on macOS. The probe trampoline emits No release carries the nehalem change yet. bun v1.3.14 is from May. The WebKit commit is from July. |
|
@Jarred-Sumner @dylan-conway @cirospaciari @alii — can this be unblocked? This PR is the direct fix for non-AVX CPU support on macOS — a regression that has been open since v1.3.9 (nearly a year). The missing darwin baseline build lane means The dependency (oven-sh/WebKit#290) is verified and complete. Once that merges, this PR is ready to go. Impact:
The fix is done. Please merge. I'd also love to contribute directly — if there's an opportunity to join the team or help push non-AVX support forward, I'm available. — @genose |
Important
Blocked by oven-sh/WebKit#290
This lane builds
darwin-x64 --baseline, which downloadsbun-webkit-macos-amd64-baseline.tar.gz. That artifact does not exist yet (HTTP 404) — oven-sh/WebKit#290 is what builds it.Until WebKit#290 merges and its autobuild publishes the tarball, this PR's CI cannot go green: the new darwin baseline lane will fail to fetch its prebuilt. Ready for review on the substance; flip out of draft once the artifact exists.
Problem
@oven/bun-darwin-x64-baselineis the AVX2 build — byte-identical to the default:Same file, same 69,173,328 bytes. Disassembly: 248,019 AVX2 (
ymm) + 7,049 AVX-512. Identical at 1.2.20 too — not a regression.Linux, for contrast, ships a real baseline:
So a pre-AVX2 Mac gets no working bun and no fallback. Downstream: opencode#29039, opencode#24876.
Root cause
A missing build lane — not the resolution logic:
.buildkite/ci.mjsbuildPlatformsbaseline: true; darwin has no baseline entrypackages/bun-release/src/platform.ts:41bun-darwin-x64-baselinenpm package → it ships anyway, fed the default binaryscripts/build/deps/webkit.tsprebuiltSuffix()-baselinefor any x64 (no OS check) → the URL was always rightThe URL is right; the artifact doesn't exist:
Fix
The fixing line — one entry in
buildPlatforms(.buildkite/ci.mjs), mirroring the linux baseline lane:Plus one stale comment in
scripts/build/deps/webkit.ts:No change to
prebuiltSuffix()orCompileTarget— already correct.Verification
Built
darwin-x64 --baseline=trueagainst a locally-producedbun-webkit-macos-amd64-baseline(WebKit's own unmodifiedmacos-cross-release.sh+MARCH_FLAG=-march=nehalem):libJavaScriptCore.a%ymm)-march=nehalem(this)bun-webkit-macos-amd64The resulting bun:
ymm)@oven/bun-darwin-x64(==-baseline)@oven/bun-linux-x64-baseline(verified on real pre-AVX2 hardware)A baseline build isn't "zero AVX2" — the residual sits behind CPUID runtime dispatch, exactly like the linux baseline. What matters is the profile matches the linux baseline (which I verified runs on a pre-AVX2 CPU), not the AVX2 default.
On the unfixed tree the target 404s on the prebuilt — which is why no darwin baseline has ever shipped.
Recipe validated on real pre-AVX2 hardware (Sandy Bridge Xeon, AVX + SSE4.2, no AVX2/FMA): the
-march=nehalemlinux baseline runs there (opencode runcompletes); the-march=haswellbuild crashes (~21 s, ~3.9 GB RSS, segfault in the simdutf path).Who this is for
Pre-Haswell Intel Macs on a macOS bun still supports.
opencode#24876:
13.7.4 clears bun's 13.0 deployment target; the CPU has no AVX2. That combination is the gap. Same reporter — who independently suggested
-march=nehalem:opencode#29039 confirms the packaging bug from the Mach-O header itself:
How they're on a current macOS: OpenCore Legacy Patcher (17.8k stars, 5,046,133 downloads on 2.4.1) runs current macOS on Macs Apple dropped, pre-Haswell included. Not all of those users are pre-AVX2 — but "old Mac, current macOS" is common, not exotic. I run it on my mom's 2013 Intel Mac; the OS is new enough for bun, the CPU isn't.
Why it's cheap
Dockerfile.macosalready takesMARCH_FLAGand setsCMAKE_SYSTEM_NAME=Darwin; darwin lanes already cross-compile on Linux under docker. One lane cloned from an existing one.bun-darwin-x64-baselineand routes non-AVX2 Macs to it. Today that resolves to a binary that can't run on the CPU it was selected for.If a baseline macOS build isn't wanted, the coherent alternative is to stop shipping the package and state that x64 macOS requires Haswell+. Right now it's neither.
Relationship to the other PRs
This is one of four pieces; none of them alone gives pre-Haswell Mac users a working binary:
bun-webkit-macos-amd64-baselineand-baseline-lto)darwin-x64-baselinebuild lane once the artifact existsOn oven-sh/WebKit#292. This lane will build and go green with #290 alone, and the resulting binary works on Sandy/Ivy Bridge — the CPUs in nearly every report on #32511/#26872. It does not work on a Mac with no AVX at all (Westmere, e.g. a Mac Pro 5,1 on OpenCore), and it does not run WebAssembly there, because JSC assumes AVX on Darwin and the JIT emits VEX regardless of
-march. Both are fixed by #292.That matters for sequencing because of what this PR is for:
packages/bun-release/src/platform.tsalready publishesbun-darwin-x64-baseline, and non-AVX2 Macs already resolve to it. Landing #290 + this PR without #292 turns "the baseline package is the Haswell build and crashes on every pre-Haswell Mac" into "the baseline package is real and crashes only on pre-AVX Macs" — a large improvement, but still a package that SIGILLs for some of the users it was selected for, which is the thing #32512 exists to prevent. With #292 in the pinned WebKit, the artifact does what its name says on every CPU that resolves to it.Since both WebKit changes land in the same repo and this PR needs a
WEBKIT_VERSIONbump anyway (below), the cheapest ordering is: #290 + #292 merge → autobuild publishes → bump the pin here to that SHA.#32512 names this exact sequencing:
That artifact now exists and is verified — oven-sh/WebKit#290 builds it with WebKit's own unmodified
macos-cross-release.sh, and itslibJavaScriptCore.ahas 0%ymminstructions vs 58,967 in the shipped Haswell one.Ordering: if #32512 lands first, this PR needs a trivial rebase to relax the
baseline && darwin && webkit === "prebuilt"assert it adds — which is precisely what #32512 says should happen once the artifact exists. If this lands first, #32512's guard should be scoped to "no baseline WebKit for the pinned WEBKIT_VERSION" rather than "never for macOS".Still needed before this can go green
WEBKIT_VERSIONbump inscripts/build/deps/webkit.tsto that autobuild. The current pin (4895f45) is WebKit main HEAD today, so the bump should be workflow-only. Not included here because the target autobuild doesn't exist yet. Ideally that pin lands on a SHA containing both can't use redux with next's #290 and fetch module errors at random times #292, so the artifact this lane ships is correct on every CPU that resolves to it.robobun's preview build on the (now closed, folded into #290) oven-sh/WebKit#291 already ran the full matrix and published
bun-webkit-macos-amd64-baseline.tar.gzand-baseline-lto.tar.gz, so the lane is known to work in real CI and not just locally: https://github.com/oven-sh/WebKit/releases/tag/autobuild-preview-pr-291-45bcadc5Also in this PR
testPlatformsgets adarwin-x64-baselineentry, matching the linux (debian/ubuntu/musl) and windows x64 baseline lanes. The shipped darwin baseline artifact has never been exercised by the test suite — which is how it shipped as the Haswell build unnoticed. Easy to drop if the Intel mac pool is too tight; flagged by robobun as a maintainer call.Fixes #32511
Fixes #26872
Both report the same thing this makes possible: a
bun-darwin-x64-baselinethat actually runs on pre-Haswell Intel Macs. Neither is fixed until oven-sh/WebKit#290 lands too — happy to drop theFixeskeywords if you'd rather close them manually once the artifact ships.Prebuilt artifacts from this exact recipe (this bun, plus an opencode compiled against it) for anyone with a pre-AVX2 Mac willing to test: https://github.com/tobocop2/opencode-bun-pre-avx2-mac/releases/latest
That build includes oven-sh/WebKit#292 as well, so it covers no-AVX Macs. A Mac Pro 5,1 (Xeon X5690, Westmere) confirmed an earlier build of it fixed the startup SIGILL: anomalyco/opencode#8345 (comment)